Commercial, off-the-shelf (COTS) computing applications sometimes need to communicate with computer-based data storage systems, protocols, and applications such as relational databases, directories, and spreadsheets. Such data storage mechanisms can be referred to as data stores. The communication between the COTS applications and the data stores can include the retrieval of data from a data store by an application and the creation, deletion, or updating of data in a data store by an application. These communication operations to and from COTS applications and data stores can be referred to generically as data requests.
COTS applications typically contain driver modules that act as interfaces between the applications and other entities. Similarly, data stores typically contain driver modules known as listeners that receive communications from applications. In order for a COTS application to communicate with a data store, a specific application driver is typically required to interface with a specific data store listener. That is, vendors of COTS applications generally certify an application and its built-in driver for use only with a particular version of a particular data store.
If a data store is replaced by a more recent version, a COTS application that had been in communication with the older version may not communicate properly with the newer version. The manufacturer of such an application may not certify it for use with the newer data store version and may cease to support its product in such a situation. Thus, replacement of a data store may necessitate the purchase of an updated version of a COTS application that is able to communicate with the new data store.
Also, when multi-step data transfer transactions take place among computing systems, errors can occur at any step in a transaction. When an error does occur in a step, it is often desirable to reverse any data changes that were made in that step and in previous steps. A two-phase commit process is sometimes followed to allow such rollbacks of data. With a two-phase commit, a copy of a data element that is to be modified by a transaction is retained temporarily. If all of the steps in a transaction are completed successfully, the copy can be discarded. If an error occurs in a step, the copy of the data element as it appeared before the transaction can be used to return the element to its previous state.
Many commercial, off-the-shelf (COTS) data stores do not have internal mechanisms that provide for transaction processing via two-phase commits or similar processes. That is, there is typically no automated method for rolling back a change that has been made to the data in a COTS data store. As used herein, the term “data store” can refer to various computer-based storage systems, protocols, and applications such as relational databases, directories, and spreadsheets.